home *** CD-ROM | disk | FTP | other *** search
/ 1,000+ Great Games / 1_1000 Games.iso / HERETIC / WARM15.ZIP / WARM15.TXT < prev    next >
Encoding:
Text File  |  1995-11-29  |  10.7 KB  |  231 lines

  1.                        WAD Auxiliary Resource Manipulator
  2.      Version 1.5 of November 1995 by Robert Fenske, Jr (rfenske@swri.edu)
  3.         Ported to OS/2 by Mark K. Mathews (mmathews@genesis.nred.ma.us)
  4.  
  5.             Summary of features
  6.             -------------------
  7.  
  8.         o The fastest NODES/SSECTORS/SEGS builder on the planet
  9.         o Fastest BLOCKMAP builder on the planet
  10.         o Fully automatic REJECT resource builder
  11.         o Manual REJECT special effect manipulation
  12.         o Works with all levels in DOOM I, DOOM II, HERETIC, and
  13.           HEXEN WAD files
  14.         o Has various utility function options, including
  15.             merging WADs and levels
  16.             extracting resources
  17.             substituting resources
  18.             randoming things
  19.             rename resources
  20.             packing/unpacking WADs
  21.         o Full source code
  22.         o Compiles and runs under these operating systems:
  23.             MS-DOS, OS/2, SunOS 4.1.x, Solaris 2.x,
  24.             Linux, FreeBSD, HP-UX, VMS, Windows/NT
  25.  
  26.             General description
  27.             -------------------
  28.  
  29.     This is release 1.5 of my WAD Auxiliary Resource Manipulator, or
  30. WARM and is an update of my previous 1.4 release of May 1995.  There are
  31. quite a number of changes between these releases (see below).
  32.     This package consists of the following fifteen files:
  33.         WARM15.TXT        This text file
  34.         DMGLOBAL.I        The include file
  35.         WARM.C            \
  36.         WADIO.C              \
  37.         NODES.C                WARM C sources
  38.         BLOCKMAP.C          /
  39.         REJECT.C        /
  40.         WARMDOS.EXE        MS-DOS executable
  41.         WARMOS2.EXE        OS/2 2.1 executable
  42.         MAKEFILE.DOS        MS-DOS GCC makefile
  43.         MAKEFILE.OS2        OS/2 2.1 C/Set++ makefile
  44.         MAKEFILE.UNX        various Unix flavors makefile
  45.         MAKEFILE.COM        VMS build script
  46.         WARMOS2.DEF        OS/2 2.1 auxiliary file
  47.         EMU387            ix86 floating point emulation library
  48.  
  49.     WARM's main purpose is to build the NODES, SSECTORS, SEGS, BLOCKMAP,
  50. and REJECT resources from the basic resources that compose a level.
  51.     Executing the program with no command line arguments will display help
  52. regarding the command line.  Note that there are several optional functions
  53. available that are unrelated to the reject, nodes, or blockmap creation.
  54. Hopefully most have an obvious function, but I'm not going to bother to
  55. exlain any of them.  These functions are in this program because I did not
  56. want to mess with more than one program to get all the functionality I wanted.
  57. Note that some of the functions (dmit and rand) are not fully implemented
  58. with respect to HERETIC and HEXEN.
  59.     To use this program under MS-DOS on a computer without a math
  60. coprocessor requires using the EMU387 floating point math emulation library.
  61. The environment variable GO32 must be set as "SET GO32=emu <dir>\EMU387"
  62. where <dir> is the directory in which you have the EMU387 file located.
  63.     The CR/LF pairs in the source code should (must) be converted to LF
  64. before building WARM on a Unix system.    Porting this code to any system I
  65. haven't already tried should be straightforward.  If the target system is
  66. big-endian, the BIG_ENDIAN define will have to be modified appropriately
  67. in WADIO.C.
  68.     Any comments, etc about WARM can be directed to rfenske@swri.edu.  If
  69. you do find any WAD file that WARM does not process correctly, please let
  70. me know about it.
  71.  
  72.             Acknowledgements
  73.             ----------------
  74.  
  75. Mark Mathews (mmathews@genesis.nred.ma.us)
  76.     Ported the code to OS/2 and performed extensive testing for the
  77.     1.1 release and prodded me enough to make me finish it.
  78.  
  79. Matt Fell (MSFell@aol.com)
  80.     His DOOM Specs provided the BLOCKMAP generation optimizations.
  81.  
  82. Jason Hoffoss (hoffo002@gold.tc.unm.edu)
  83.     The author of DMAPEDIT came up with the packed BLOCKMAP idea.
  84.  
  85. Bernd Kreimeier (Bernd.Kreimeier@nero.uni-bonn.de)
  86.     Came up with the idea of not creating segs (during node generation)
  87. for those lines that do not affect the display in any way.
  88.  
  89.             BSP Generation Smarts
  90.             ---------------------
  91.  
  92.     Some lines in a level do not affect the display in any way; these
  93. lines are those that have no floor nor ceiling changes on either side of them
  94. and do not have a texture on them.  So visually, you can not tell there is
  95. a line present while playing the game.  Thus there is no reason for these
  96. lines to be considered during node generation.  Doing this will create fewer
  97. NODES, SSECTORS, and SEGS (thus a smaller WAD).  There is an option to disable
  98. this feature since some special effects require that these non-visual lines be
  99. present in the SEGS list.
  100.     There are two options that can be given to the node builder, the
  101. "a" option and the "u" option.  The "a" option stands for "all SEGS" and
  102. the "u" option stands for "unique sector".  The "a" option controls the
  103. processing described in the preceeding paragraph.  This option usually must
  104. be present to make special effects like transparent platforms, lifts, etc
  105. work.  This is because all the SEGS must be present in the SEGS list to
  106. properly fool the DOOM engine into producing the intended display.  The "u"
  107. option controls whether SSECTORS can be created from more than one sector
  108. (i.e. from SEGS attached to different SECTORS).  Normally SSECTORS are only
  109. created from SEGS from the same sector and so this option is on by default
  110. (and in rare cases must be on).  Currently, the only time that I know of
  111. that this option needs to be disabled ("!u") is for transparent doors.
  112.  
  113.             HEXEN BSP Requirements
  114.             ----------------------
  115.  
  116.     HEXEN WAD files can contain extended objects called polyobjects.
  117. These objects, such as doors that open away from the player require that
  118. the area containing the polyobjects not be split by any partition line
  119. created during the BSP generation.  WARM currently has no mechanism to
  120. recognize these objects and build the BSP tree around them.  If a WAD doesn't
  121. work, try building the BSP tree with the -n=a option.  If it still doesn't
  122. work, then you'll have to change the WAD.
  123.  
  124.             Packed Level Data
  125.             -----------------
  126.  
  127.     The resource data that forms a typical level can have a significant
  128. amount of redundant and unused data.  The unused data consist of unused
  129. SIDEDEFS, VERTEXES, and SECTORS that are not referenced by any of the other
  130. resources and do not contribute to the level that a player sees.  Unused
  131. data is more prevalent in older WADs; most WAD editors now automatically
  132. remove unused data before the level data is saved.  WARM currently does not
  133. attempt to remove unused level data.  The redundant data consists of redundant
  134. VERTEXES and SIDEDEFS entries.  Removing redundant SIDEDEFS entries can
  135. significantly reduce the size of the level data.  The drawback to removing
  136. duplicate SIDEDEFS is that it can make further editing of the level difficult,
  137. especially if LINEDEFS and/or SIDEDEFS have to be deleted.  Thus any packed
  138. level should be unpacked if further major editing is required.  Lastly, the
  139. level's BLOCKMAP is packed (see below).
  140.  
  141.             Packed BLOCKMAP
  142.             ---------------
  143.  
  144.     Each block in the BLOCKMAP represents a 128x128 region of the map
  145. area.  Many of these regions will be empty, i.e. no LINEDEFS exist in these
  146. regions.  A normal BLOCKMAP will have a separate entry for each of these empty
  147. regions.  However, doing so is unnecessary.  A single entry in the BLOCKMAP
  148. can represent all of the empty blocks.  Having such a single entry can
  149. typically reduce the size of the BLOCKMAP by 1/3.
  150.  
  151.             REJECT generation algorithm
  152.             ---------------------------
  153.  
  154.     Since I have not seen any other program that does fully automatic
  155. REJECT generation, I give an explanation of what the builder does in the
  156. following paragraphs.
  157.     The algorithm for generating the REJECT resource is given in the source
  158. code.  Basically, it is built from strictly line of sight determinations
  159. between all sector pairs.  For each sector pair, a check is made as to whether
  160. any one-sided lines block the view of a chosen two-sided line from each sector.
  161. I.e., if one-sided lines block the views of all two-sided lines of one sector
  162. from all the two-sided lines of the other sector, then the sector pair is
  163. deemed not in sight of each other.  Otherwise, the sector pair can see each
  164. other (obviously).  However, the method used is not perfect and will not catch
  165. all instances of line-of-sight.
  166.     For each pair of test points, all potentially blocking one-sided lines
  167. must be checked.  To avoid having to check all the one-sided lines of each
  168. level, the BLOCKMAP is used to greatly limit the search.  Since the BLOCKMAP
  169. is a record of which lines are in each 128x128 block of the map, and since it
  170. is fairly easy to compute which blocks are between a pair of test points, the
  171. BLOCKMAP provides a ready list of only those one-sided lines that are
  172. potentially in the way of line of sight.  Even with this method, the process
  173. is still computationally expensive; for large levels the REJECT computation
  174. takes far longer than the nodes generation.  The program does have an option
  175. to produce just a zeroed REJECT resource, so the possibly lengthy computation
  176. time can be avoided.
  177.  
  178.             Version History
  179.             ---------------
  180.  
  181. 1.5  November 1995    o Fourth released version
  182.             o Added HEXEN support
  183.             o Significantly faster node generator
  184.             o Fixed problem with directory function
  185.             o Fixed problem with rename function (couldn't rename
  186.               more than one resource at a time)
  187.             o Fixed problem with extract function
  188.             o Fixed -map## option (broken in v1.4)
  189.             o Fixed problem with merge function
  190.  
  191. 1.4  May      1995    o Third released version
  192.             o Fixed split SEGS offset problem in node generator
  193.             o Removed redundant vertex creation in node generator
  194.             o Optimized node partition line computation so node
  195.               generator is now faster
  196.             o Node generator now ignores certain lines when
  197.               creating node tree; added option list to -n to
  198.               enable/disable this action
  199.             o Improvements to the emstat() routine
  200.             o Added negation ability and sector # wildcarding in
  201.               reject exception specification; removed -x option
  202.               and moved exception list to -r
  203.             o Added pack and unpack functions
  204.             o Better command line help
  205.             o Added quiet output option
  206.  
  207. 1.3  April    1995    o Second released version
  208.             o Implemented packed blockmap
  209.             o Added unique sector method to node generator
  210.             o Reject generator is faster
  211.             o Improvements to the dmit() routine
  212.             o Improvements to the emstat() routine
  213.             o Added rename function
  214.             o Fixed memory usage bug in node generator (only
  215.               affected Linux executable)
  216.             o Tested under FreeBSD, HP-UX, VMS, and Windows/NT
  217.  
  218. 1.2  February 1995    o Never released
  219.             o Experimental optimizations that didn't really speed
  220.               anything up
  221.  
  222. 1.1  January  1995    o First released version, compiled for MS-DOS, OS/2,
  223.               SunOS, Solaris, Linux
  224.             o Fixed obscure bugs in the nodes, blockmap, and reject
  225.               generation routines
  226.             o Added Deathmatch v2.0 option to dmit() routine
  227.  
  228. 1.0  August   1994    o Never released, update of original VNB program
  229.             o Compiled for MS-DOS and SunOS
  230.             o Includes automatic reject builder
  231.